SGI Developer Toolbox 6.1

home *** CD-ROM | disk | FTP | other *** search

/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / networking / slip.config.general < prev

Wrap

Text File | 1994-08-02 | 39.1 KB | 974 lines

~4Dgifts/toolbox/documents/networking/slip.config.general This document was written by one of SGI's net-gauds for people on SGI machines attempting to implement SLIP. SLIP INSTALLATION AND CONFIGURATION GUIDE SLIP (Serial Link Internet Protocol) and PPP (Point to Point Protocol) are two ways of extending a TCP/IP network over point-to-point links (like phone lines). They can be configured as dialout only, dialin only, or bidirectional (the union of dialin and dialout). These instructions are designed for Irix SLIP in Irix releases 4.x and 5.x, Irix PPP in Irix release 5.2, and the third-party product MorningStar PPP on Irix release 4.x (Note that MorningStar PPP is a licensed, third-party product, and must be purchased from Morning Star Technologies, Inc, email to sales@morningstar.com for info). There is currently little GUI (visual tool) mechanism for configuring modems, much less configuring SLIP or PPP. Therefore, configuration involves working in a shell, and these instructions presume at least limited familiarity with a straight text editor, such as vi. DOCUMENT SUMMARY: This document contains the following major sections: SOFTWARE INSTALLATION STATUS: is SLIP or PPP installed? MODEM SELECTION: what kind of modems to get. MODEM INSTALLATION: how to install and configure the modem SELECTING THE IP ADDRESS FOR SLIP OR PPP: how to get from here to there ORIGINATE (DIALOUT) CONFIGURATION: configure software for dialout ANSWER (DIALIN) CONFIGURATION: configure software for dialin SECURITY: keeping the bad guys out ADDING DIALIN MODEMS: setting up the modems to answer the phone ADDING SLIP OR PPP CLIENTS: Enabling them to dialin ADDITIONAL CONSIDERATIONS: miscellaneous info DEBUGGING: when things go wrong APPENDIX currently only contains one entry: SAMPLE GATED.CONF FILES: to route between LANs connected by SLIP or PPP SOFTWARE INSTALLATION STATUS: Make sure that you have the software properly installed before you attempt to configure anything. You need to have the standard but non- default Irix subsystems eoe2.sw.uucp and eoe1.sw.slip (for pre-5.2 Irix) or eoe1.sw.ppp and eoe2.sw.slip (for Irix-5.2) installed. You can check whether they are installed with the "versions" command and should show something like the following: % versions -a eoe\?.sw.{uucp,slip,ppp} I = Installed, R = Removed Name Date Description I eoe1 01/24/94 IRIX Execution Environment 1, 5.2 I eoe1.sw 01/24/94 IRIX Execution Environment Software I eoe1.sw.ppp 01/24/94 Point-to-Point Protocol Software I eoe2 01/24/94 IRIX Execution Environment 2, 5.2 I eoe2.sw 01/24/94 IRIX Execution Environment Software I eoe2.sw.slip 01/24/94 SLIP Software I eoe2.sw.uucp 01/24/94 UUCP Utilities Because MorningStar (aka MST) PPP is a third-party product with a kernel driver, software upgrades will, in effect, "de-install" it. After doing an Irix software upgrade, you will probably have to reinstal the MST PPP kernel driver, and rebuild a new kernel. Configuring Irix SLIP, Irix PPP and MST PPP are very similar, the main difference is the directory where the software resides is different, and each has a different way of specifying options. MODEM SELECTION: A number of different modems have Dialer entries and configuration scripts for use with Irix SLIP and PPP and MST PPP. Generally, you just need a high quality V.32 or faster modem. Under most circumstances you should avoid using proprietary modem protocols such as PEP or HST, and stick with the standard ones ("V" protocols). A short diversion on the "V." number protocols: These are CCITT standards for modems, and allow modems from different manufacturers to interoperate (talk to each other). Some of the standards refer to modem carrier (or modulation) speeds, and others refer to additional protocols. The ones of interest include: V.32 -- 9600bps full-duplex modulation V.32bis -- 14400bps full-duplex modulation, fully compatible with V.32 V.42 -- end-to-end error correction, runs "on top of" V.32, etc V.42bis -- data compression, theoretically capable of 4:1, more commonly gets 1.5:1 to 2.5:1 on non-compressed data. In practice, usually limited by DTE speeds. The following are "in-process" standards, which may be of interest, as some modems already support a variant of them: V.32ter -- 19200bps extension of V.32bis, being driven by industry co-operation, while waiting for V.34 V.FAST -- 28800bps, still in R&D and specification refinement V.34 -- the final name of the V.FAST standard Because of the existence of V.42bis data compression, it is no longer usefull to have the DTE (aka "serial port") run at the same speed as the modulation. In general, the DTE should be set to the highest speed common to both the modem and the computer, and hardware flow control (aka RTS/CTS flow control) is used to prevent data overruns (or data losses). Modern modems and computers will handle 38400bps or faster DCE speeds. The following modems have Dialers entries and configuration scripts that make them easier to use for Irix SLIP and PPP: Telebit T2500, T1600, QBlazer, T3000, and WorldBlazer ZyXEL U-1496 (all versions) Intel 14.4ex DSI 9624 models USRobotics Hayes ACCURA almost any true Hayes compatible can be made to work. MorningStar supports a large number of modems (see their documentation for the current list). MODEM INSTALLATION: The modem needs to be attached to one of the serial ports with a real modem cable. At the moment you cannot buy a third-party, mass-market modem cable for an IRIS workstation or server. Some of the newest Mac modem cables *may* work for the Indigo line, but most Mac modem cables handle *either* Modem Control lines *or* Hardware Flow Control lines, but *not* both. You need a cable that handles both (all seven lines) to run a SLIP or PPP connection on an IRIS. A number of SGI cable part numbers are available. It is currently unclear whether all were actually manufactured (or read `man serial` and build your own): Indigo2 Owner's Guide 018-8114-001 Indigo to dumb terminal p. 5-21 X5-25TO8 Indigo to modem cable p. 5-22 X5-9TO8 Indigo to SGI/high-end (dials/buttons) p. 5-23 X5-ARCTO8 Indigo to PC (ARCS!) p. 5-24 Note that "Indigo" referes to Indigo, Indigo2, and Indy unless otherwise stated. Selecting a port to use: on graphics machines, any port can be used. The low-end machines (PI, Indy and Indigo family) only have 2 serial ports, and either can be used, although port tty1 will need to be specially configured. The larger machines generally have more than 2, and more can be added using the CDSIO 6-port serial board. A server (non-graphics) machine cannot use port tty1, because that is the console port. Serial port tty1 is the Alt(ernate) Console port, and must be disabled if you wish to use a modem on it. You will need to edit /etc/inittab and change the "Alt Console" line from "respawn" to "off". Irix supplies scripts for automatically configuring a modem for use with SLIP or PPP. The scripts are in /usr/lib/uucp, and the names all start with "fix-". On a 5.2 system, the following fix- scripts are available (these are also available for 4.0 systems by anonymous ftp from ftp.sgi.com:/sgi/modems): fix-dsi fix-hayes fix-intel fix-telebit fix-usr fix-zyxel Assuming you wanted to program a dialout Telebit T3000 to run at 38400bps on port 2 you would give the following command: /usr/lib/uucp/fix-telebit -o -m t3000 -s 38400 2 This would normally only need to be performed once. Using the "-io" option instead of "-o" will setup a modem usable for dialin, dialout, or both. SELECTING THE IP ADDRESS FOR SLIP OR PPP IP address selection and routing are intimately connected. You cannot discuss one without at least mentioning the other. Routing is how the packets know where to go in the network. Using a wrong IP address can screw up routing for more than just the machine with the wrong IP address, in worst case it can cause the whole network to fail! Fortunately, we've never seen anything approaching worst case yet. IP addresses are not selected at random, they are assigned by certain administrator(s) within your organization, with ultimate authority from the NIC (Network Information Center) that arbitrates the whole Internet. Terminology: I will refer to the host running SLIP that is connected to the larger network (sometimes the Internet) as the "server" host, and the host running PPP connected to the smaller network as the "client" host. In particular, if there is only the one machine on the client network, it is known as "isolated" or "stand alone". Unless otherwise stated, "SLIP" and "PPP" are interchangeable in this section. The IP address for a SLIP-client is determined by the IP network that the SLIP-server is connected to. There are 3 general cases to consider, and one special case (also referred to as a "borderline" case). The first two cases deal with stand-alone or isolated machines. There is a fuzzy deviding line between "a few" and "a lot" of standalone hosts desiring to be SLIP-connected to one network. 1-5 hosts is definitely "a few", 50 is definitely "a lot". The difference is that "a few" put the clients on the same IP network as the server(s), and "a lot" puts all the clients on their own "slip-net", using another IP network number. IP network numbers are in limited supply, so it make sense to not "waste" them. The first case deals with "a few" isolated IRISes to become SLIP clients. Each client is expected to not grow into a multiple-host network site, for which this technique is not appropriate (although there is a special case that mostly works). In this case, the easiest solution is to take an IP address on the network of the server. The client will setup a default route through the SLIP interface, and the server will do "proxy arp" for the client. This makes the least demands on routing: on the client, the rest of the world is accessed via the SLIP interface; and the server acts in proxy for the client for packets going the other way. The client will have it's Ethernet interface disabled, the simplest method is via `chkconfig network off`. For example, the case of an Indigo connecting via SLIP to a WAN site. Follow a packet when doing `ping foo.bar.com`: IP first looks up foo.bar.com in /etc/hosts, and finds it (192.2.3.4). The IP address is not the same as the local host, so IP looks in the routing table for the interface to use for the 192.2.3.0 network. The only one that matches is "default" points to the SLIP interface. The packet gets shipped across to the server, where IP routing on the server takes over like normal. The packet eventually makes it's way to foo.bar.com, where the echo-server (ping server) sends a return packet. Routing gets the packet back to the SLIP-server's network. It uses ARP (Address Resolution Protocol) to determine the Ethernet address for SLIP-client's IP address, and SLIP-server responds "me! me!" SLIP-server knows to send the packet over the PPP link, back to client. (I'm not going into this detail again!). In short, after slip or pppd starts, on the client you would execute the command: route add net default <server> 1 (in Irix-5.1 and later this can be done automatically by the slip or ppp process, see the man pages) and on the server, the command: arp -s <client> `netstat -ia | grep :` pub The second case for "a lot" of standalone hosts is to assign an IP network number for the use of SLIP or PPP clients (a "slip-net"). It is simpler in some respects than the previous case. Each client will get an IP address out of the slip-net. The client needs to setup a default route like above. The server can use the standard Irix routed configuration (although adding the "-q" or "-F slip-net" option to routed will increase available bandwidth). The client does not need to disable the ethernet port unless it needs to communicate with other hosts on the slip-net, in which case both need to `chkconfig network off` (or the equivalent). You could, in fact, set up a small remote LAN using the slip-net, but you would forever give up the ability to communicate with other, non-local, hosts on the slip-net (well, it would be *really* tricky to configure). Routing to let the other machines communicate would be very tricky. You can use the slip-net with servers on multiple nets as long as one important criteria is met: the routers on *ALL* possible routes between the networks must pass host routes correctly. Currently, IRIS routers do this, and Cisco's do not (in the current software releases, though they can be configured to not screw things up, they don't forward host routes, but do stop munging them). I don't know about other router brands. This is the most "hands-off" mechanism, but is usually not justifiable for small numbers of SLIP hosts. An alternative to `chkconfig network off` is to leave the host's IP address to the default (192.0.0.1), and have slip or ppp use the assigned IP address as the non-default local address ('-l <local>' option to Irix SLIP, see the man pages for the others). The other major case is connecting a small remote LAN to a larger one (usually an institutional LAN or WAN). In this case, the remote LAN would be given it's own IP network number, and the SLIP- or PPP-client would get one of them. Routing issues are much more important. Both hosts running PPP will also have to run gated so as to advertise the appropriate network routes to the other hosts on their respective LANs. The SLIP-client will have a static default route to the SLIP interface as in the previous case, but gated will advertise the default route to the other machines on the LAN. The SLIP-server will run gated to advertise the network route via the SLIP link to the remote LAN. In addition, Cisco (and other brand) router(s) communicating via IGRP in a WAN-type configuration may need to have it's configuration modified to know about the additional IP network that it needs to route for. Since gated is difficult to configure, other approaches include setting up a static route on each of the client-side hosts, or have another machine (eg: the Cisco router) advertise the route. Sample /usr/etc/gated.conf files will be listed at the end of the file. Note that I am by no means a gated expert (or even novice, yet), but these configurations have been known to work in some cases. I don't know how to specify the netmask yet, since it may be important for some sites. The special case is a very small LAN consisting of 2 (or at most 3) hosts connecting via SLIP or PPP to the campus LAN directly. It may have grown out of the isolated host case, or an site that is expected to never grow any more. All the hosts are assigned IP addresses from the IP network of the PPP-server. The server will proxy-arp for all of the remote hosts, and the PPP-client will need to arp for all of the hosts on the other side that they care about getting to. At a minimum, this will be the router, the mail relay machine, and any server machines. In addition, the client will have a static default route pointing to the PPP interface, and each of the other machines needs a static default route pointing to the PPP-client. Because of the need to maintain the ARP tables up-to-date, moving machines around can cause mysterious failures of the network. NOTE: because of arp caches, changes to the arp tables (via the arp command) may not take affect immediately. This can cause routing problems until either the cache expires after the arp mapping is explicitly deleted (via `arp -d` on IRISes, or removing the host). The default arp cache timeout is 20 minutes on IRISes, 4(?) hours on Cisco routers. For others, you'll need to check the documentation or ask the vendor. ORIGINATE (DIALOUT) CONFIGURATION: This involves modifying several configuration files. The information needed to perform the configuration includes: local hostname & IP address remote hostname & IP address modem type phone number login password framing (SLIP or PPP) IP address of a nameserver so that DNS can lookup host names The edits are organized by configuration file: /etc/hosts: really only needs 3 entries, as all others can be obtained from the nameserver after a connection is made. The hosts file could look like (with appropriate substitutions): 127.0.0.1 localhost loghost xx.yy.zz.ww <myname>.<domain>.sgi.com <myname> aa.bb.cc.dd <remote>.<domain>.sgi.com <remote> 224.0.0.0 multicast ~uucp/Devices: (~uucp is /usr/lib/uucp in Irix4, /etc/uucp in Irix5). This is common for all versions, to allow the use of cu for debugging connection problems. Make all additions and changes at the bottom of the file to simplify future updates. Assume using port tty2 for the example: Direct ttyd2 - Any direct Direct ttym2 - Any direct Direct ttyf2 - Any direct For SLIP and Irix PPP connections, edits are to files in ~uucp: ~uucp/Devices: Based upon the modem type (assume Telebit T3000 at 38400bps and port tty2 for the example), add the following to the bottom of the file for each dialout modem. If all modems are "equivalent" (any modem to any destination), then use the same label for each modem (ACUslip), otherwise you'll need to make different labels for each class of modem. Make sure that the last field (t3000 in the example) is in your dialers file, or it will fail "mysteriously"! ACUslip ttyf2 null 38400 212 x t3000 ~uucp/Systems: This is the "smarts" for dialing the modem and logging in to the server (to start SLIP). This is a "standard" chat script, modifications may be made in some circumstances. Put the entries at the end of the Systems file. There may be more than one line with the same <remote> name, to use either a different modem or a different phone number (or both) (note this should all be on one line) <remote> Any ACUslip 38400 <phone_number> "" \r\c ogin:--ogin: <login_name> assword: <password> <framing> Since both Irix SLIP and Irix PPP send out a message with the framing name before actually starting the protocol, adding a final match of "SLIP" or "PPP" will ensure that the login really succeeded. I make the convention or prefixing <remote> with "S" for SLIP or "P" for PPP, followed by the hostname. There are several ways to start a SLIP connection. You don't have much choice under Irix4 -- /usr/etc/slip dials the phone as soon as it is started, and will not automatically setup a route. Irix5 has a daemon mode, and can automatically startup a route. You will need to do something like the following (either manually, or in a script). It is recommended to use the cslip mode (aka Van Jacobson Header Compression) whenever possible, as it makes the link feel more responsive by decreasing latency. See `man slip` for more detail. Irix4 version (can do it in Irix5 also): /usr/etc/slip -o -c -p cslip -r <remote> & [wait for the connection message] /usr/etc/route add net default <remote> 1 # only on a client!!!! Irix5 version can be configured to start on boot, and will do dynamic link management. Something like the following script can be put in /etc/init.d/network.local (or whatever), and a link added in /etc/rc2.d to start it up at boot time. NOTE: don't use the '-R ""' option on a server! See `man slip` for more info. Note: <chat_name> is the first field of the Systems entry if it is different than the hostname of the remote. #!/bin/sh # slip boot startup script case $1 in start) /etc/killall slip /usr/etc/slip -q -p cslip -R "" -r <remote> -u <chat_name> & ;; stop) /etc/killall slip ;; esac Irix5 PPP is very similar, but options are handled differently -- all of the options are put in the file /etc/ppp.conf. See `man ppp` for details and instructions; mostly the defaults are fine. Probably the most important options are "in" for a dialin-only server, and "quiet" for the autodial client and bi-directional dial server. A startup file would look similar to the SLIP example. This example will also show adding a chkconfig option check. Note that "rmt" is only a label in /etc/ppp.conf, similar to "-u" option to Irix SLIP. #!/bin/sh # ppp boot startup script case $1 in start) /etc/killall ppp if /etc/chkconfig ppp && test -x /usr/etc/ppp ; then /usr/etc/ppp -r rmt & fi ;; stop) /etc/killall ppp ;; *) echo "usage: $0 {start|stop}" ;; esac The entry in /etc/ppp.conf for this situation might look like: rmt quiet remotehost=server lochost=client add_route uucp_name=Pserver Where "lochost=client" specifies the IP address of the local end of the PPP link, if different from the hostname, and Pserver is the entry in the /etc/uucp/Systems file. (Note that there is a typo in the 5.2 ppp man page, and "add_route" is the correct spelling). MorningStar PPP for Irix4 is configured similarly to Irix5 SLIP, but the files are in a different directory: /usr/etc/ppp, and the syntax is slightly different. First `cd /usr/etc/ppp`: cp Devices.ex Devices Then add a line at the end for each modem like: T3000 ttyf2 38400 cp Systems.ex Systems Then add at the end of the file lines like (again, it should all be on one line): <remote> Any ACU 38400 <phonenumber> "" \r\c ogin:--ogin: <login> assword: <password> cp Startup.ex Startup And edit near the end to add the lines (again, don't add the route command if you are a server!) [`man pppd` for more options]: pppd `hostname`:<remote> auto idle 300 passive vjcomp filter \ /usr/etc/ppp/Filter log /usr/adm/pppd.log route add net default <remote> 1 echo ' <remote>\c' Then give the command: chkconfig pppd on To enable pppd to automatically startup on boot. For any of the dynamically dialed setups (Irix5 `slip -q`, Irix5 ppp with "quiet" option and MST PPP with "auto" option), you can start a link via a ping or rlogin or almost anything that wants to go over the link. They will timeout and hangup the phone after a programmable idle time, then re-dial when the traffic resumes. This can save a lot of money if you are connecting long distance! The idle times are configurable (see the respective man pages). Note that it takes about 30 seconds for the first packet to get through when starting an idle line, so active timeouts much less than a couple of minutes are not very useful. ANSWER (DIALIN) CONFIGURATION: A SLIP or PPP server is easier to configure than a SLIP or PPP client, but security is far more important, since it is required to have dialable modems. There are three parts to configuring a server: setting up the modem (or modems), setting up the security on the machine, and adding the capability for SLIP or PPP client(s) to dial in. SECURITY: There must be no un-passworded accounts on the machine. Many of the standard accounts are not intended to be logged in to (especially on a server), so they can be disabled by placing a "*" in the second field of /etc/passwd. Accounts in this category include: sysadm, diag, daemon, bin, uucp, sys, adm, lp, man, nobody, nuucp, tutor, demos and 4Dgifts (also rfindd on Irix5). Active accounts that need good passwords include: root, guest, and all user accounts. A "good" password is one that is difficult to guess, especially by an external "cracker". The guest account can still be open to the network by creating a ".rhosts" file, as follows: % su # echo "+ +" >~guest/.rhosts # chown root.sys ~guest/.rhosts # chmod 640 ~guest/.rhosts # chmod +t ~guest # exit % Note that NIS accounts (aka YP, ones that start with a "+") are at least as important to check as the local ones, and may be harder to deal with. If there is a /.rhosts file, it is mandatory that it be minimal and secure. Minimize the number of entries! % su # chown root.sys /.rhosts # chmod 400 /.rhosts # exit % Passwords may be added to accounts either via the System Manager, or from a shell as follows: % su # passwd nuucp Changing password for nuucp on <host>. New password: Re-enter new password: # exit % To help prevent unauthorized access to the network by outsiders, the dialup password facility should be enabled. This is done by creating the two files /etc/dialups and /etc/d_passwd. The following example will allow SLIP connections but not UUCP or interactive dialups via modems attached to ports 1 and 2: /etc/dialups: /dev/ttyd1 /dev/ttym1 /dev/ttyf1 /dev/ttyd2 /dev/ttym2 /dev/ttyf2 and /etc/d_passwd: /bin/csh:*: /bin/tcsh:*: /bin/sh:*: /bin/ksh:*: /usr/lib/uucp/uucico:*: /usr/etc/remoteslip:: /usr/etc/ppp:: /usr/etc/dbslip:: /usr/etc/ppp/Login:: ADDING DIALIN MODEMS: Each server may have one or more dialin modems (2 maximum on Indigo, Indy and PI, more on ASD machines or if using CDSIO boards). The file "/etc/inittab" will need to be modified as follows to add modems: The original lines about 20-30 lines from the top (note that this changes in detail from release to release): # # Use the ttym* or ttyf* device names and the du_* or dx_* gettydefs tags # for ports with modems. See the getty(1M), uugetty(1M), init(1M), # gettydefs(4), and inittab(4) man pages. # # on-board ports tp:23:respawn:/etc/getty tport co_9600 # textport t1:23:respawn:/etc/getty ttyd1 co_9600 # alt console t2:23:off:/etc/getty -N ttyd2 co_9600 # port 2 t3:23:off:/etc/getty -N ttyd3 co_9600 # port 3 t4:23:off:/etc/getty -N ttyd4 co_9600 # port 4 # change to look like (assuming 2 modems, a T2500 and a T3000): # # Use the ttym* or ttyf* device names and the du_* or dx_* gettydefs tags # for ports with modems. See the getty(1M), uugetty(1M), init(1M), # gettydefs(4), and inittab(4) man pages. # # on-board ports tp:23:respawn:/etc/getty tport co_9600 # textport t1:23:respawn:/usr/lib/uucp/uugetty -Nrt20 -it25in,conn ttyf1 dx_19200 # t2:23:respawn:/usr/lib/uucp/uugetty -Nrt20 -it16in,conn ttyf2 dx_38400 # t3:23:off:/etc/getty -N ttyd3 co_9600 # port 3 t4:23:off:/etc/getty -N ttyd4 co_9600 # port 4 # use "-it25in,conn" for T2500 modems, and "-it16in,conn" for T1600, T3000 and QBlazer. If only one modem is in use, the unused port(s) should be "off" instead of "respawn". NOTE: If the server is a graphics-less machine, don't change the "t1" line, as it is used by the console terminal, and can't be used for a modem. After making the changes, type the following command for each modem installed (use the approriate modem type, t2500, t1600 (for t3000 also on Irix4), instead of qblazer if needed): % su # /usr/lib/uucp/fix-telebit -i -m qblazer 1 # /usr/lib/uucp/fix-telebit -i -m qblazer 2 Many systems can benefit from using 38400 serial speed. Not all modems or SGI machines can communicate at 38400, and the software support is not complete until 5.0. 38400 capability can be added by adding the following line to /etc/gettydefs if it doesn't exist: dx_38400# B38400 # B38400 SANE TAB3 HUPCL #\r\n\n$HOSTNAME login: #dx_38400 If installing Morningstar PPP, just use the same /usr/lib/uucp/fix-* scripts as when configuring the modem for SLIP: % su # /usr/lib/uucp/fix-telebit -io -m t3000 -s 38400 2 And a /etc/inittab entry for 38400 might look like: T2:23:respawn:/usr/lib/uucp/uugetty -Nt15 -it16in,conn ttyf2 dx_38400 # modem port After all of the modems have been configured, give the command: % su # /etc/telinit q to have the changes take effect. ADDING SLIP OR PPP CLIENTS, and enabling them to dialin: The following information is needed to configure a SLIP or PPP dialin, and needs to match exactly what was used to configure the client: the client's hostname and domainname (this should be in NIS/YP, DNS, and (maybe) /etc/hosts). The IP address must match. the loginname and password that will be used by the SLIP login Two files need to be edited for each client: "/etc/passwd", "/usr/etc/remoteslip" for Irix SLIP, "/etc/ppp.conf" for Irix PPP and /usr/etc/ppp/Login for MST PPP. For the sake of example, we will use a client hostname of "client.domain.sgi.com" with a username of "Sclient" and a password of "password". The line to add in /etc/password will for Irix SLIP look like (make sure that the login home directory exists!): Sclient::0:0:SLIP login client.domain.sgi.com,,:/usr/spool/uucppublic:/usr/etc/remoteslip for Irix PPP will look like: Pclient::0:0:Irix PPP login client.domain.sgi.com,,:/usr/spool/uucppublic:/usr/etc/ppp and for MST PPP look like: Pclient::0:0:MST PPP login client.domain.sgi.com,,:/usr/etc/ppp:/usr/etc/ppp/Login the password can be set by (for SLIP, PPP is similar): % su # passwd Sclient Changing password for Sclient on server. New password:password Re-enter new password:password # The password is not echoed. for Irix4 SLIP clients, add a section like the following to "/usr/etc/remoteslip" (routing on clients is a bit of a problem, though): Sclient) exec /usr/etc/slip -i -p cslip -r <client>.<domain>.sgi.com ;; # For Irix5 SLIP clients, routing on clients is easier because of the -R option: Sclient) exec /usr/etc/slip -i -p cslip -R "" -r <client>.<domain>.sgi.com ;; # The following section must remain the last one in the file: *) exec /usr/etc/slip -i -r $USER ;; esac Because PPP is able to dynamically configure things during the login sequence, you generally do not need to edit /usr/etc/ppp/Login (for MST PPP). You may need to edit /etc/ppp.conf for Irix PPP. If you do need something special for one or more clients, it can be edited similarly. See the man page for details, but a minimal dialin-only server /etc/ppp.conf that negotiates the client's IP address might look like: rmt in remotehost=0.0.0.0 Where "rmt" is the login for the dialin-only clients. ADDITIONAL CONSIDERATIONS: If the connect time of each individual client is expected to be low, then there does not need to be as many server modems as there are clients to dial into the site. All of the clients should be able to connect to all of the servers, and the phone lines should be set up in a "hunt group" (aka "rotary"). Then any client calling in will get the first available server modem. And for the obscure bug of the month award: If you are changing a connection from SLIP to PPP or vice-versa, you will need to reboot both machines before packets will pass. The reason is deep in the kernel routing mechanism. If you are really good a mucking around in /dev/kmem, you might be able to avoid a reboot, but I advise against it. If there are two interfaces to the same remote address, the kernel will always use just one of them, which may not be the one you want or expect. If you see something like the following output from `netstat -i`, then you must reboot before things will work: % /usr/etc/netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ec0 1500 192.82.181 starstruck.losa 16704753 2490 14890682 98 14870035 lo0 32880 loopback localhost 2142995 0 2142995 0 0 du0* 1500 (pt-to-pt) corvette.losang 2364 0 106924 0 0 sl0* 512 (pt-to-pt) corvette.losang 5 1 0 0 0 sl1* 1006 none none 0 0 0 0 0 sl2* 1006 none none 0 0 0 0 0 sl3* 1006 none none 0 0 0 0 0 du0 and sl0 having the same address is the culprit here. DEBUGGING Things don't always work the way you expect or want them to. Things either don't work, or stop working. Here are some things to check. Since most modems are setup to let you heare them dial, this is a good first starting point. If you can here the modem dialing, then go to the "turn on debugging" section, otherwise you need to check for more fundamental configuration issues. First, do a fundamental sanity check of the hardware: make sure that the modem is plugged in, turned on, and the modem cable is securely connected to both the computer and modem. Double check that it is plugged into the same serial port that you configured it -- don't setup the configuration to use /dev/ttyf2 and then plug the modem cable into port 1 on the back of the computer! Second, most modems have two phone jacks on the back, one goes to the wall jack (usually labelled "line" or "wall") and the other is for plugging a telephone into the same phone line (usually labelled "phone"). Make sure that you are plugged into the correct jack. This is an easy error if you deal with more than one modem, because each modem brand has a different jack on the left. Plug a phone into the second jack on the modem if it has one (or in place of modem otherwise), and try dialing the phone number the modem is supposed to dial. Be careful, because if the number is correct, you'll get a modem squeal in your ear. If you don't, then either the number is incorrect, there is a problem with the phone line, or the modem isn't setup correctly on the other end. Although not strictly hardware, it is worth checking that you are using the same speed (19200 or 38400) everywhere (Devices and Systems files), and that you gave the same speed option to the fix-* configuration script. The modems are configured to use a fixed speed, and most won't even talk at a different one. Any experience you may have had with "autobaud" modems is misleading. Next: turn on debugging, to see what is *really* going on, not what you thought you set up. For Irix SLIP and PPP: add '-d' option to the command. THe more "d"s, the more debugging. One "d" is usually enough for the first pass of testing. To check out the answering PPP, you will have to add "debug=1" (larger number for more debugging) to the line in /etc/ppp.conf, the debugging output goes to /usr/adm/SYSLOG. For MorningStar PPP, add "log - debug 2" (the "-" is to send debugging info to the terminal, use larger numbers for more debugging). You are really interested in only a few key points in the debugging output. The debugging format is different for each program, so I will point out what to look for. The first thing is to make sure that it is really talking to the modem. Among the debugging lines that go by will be a line that tells you which port it is trying to use, which speed it is using, and what dialer script it is trying to use. These should match what you configured. The usual problem at this point is a chat script error. Here is a sample successful login using Irix PPP to a Telebit NetBlazer (my comments are enclosed in braces "{}"): # ppp -dd -r slipserv ppp slipserv: LCP initialized ppp slipserv: IPCP initialized conn(Pslipserv) {the Systems file name} Device Type ACUSLIP wanted Internal caller type 212 Use Port /dev/ttyf1, acu - /dev/null, Phone Number x< {the tty} /dev/null is open filelock: ok filelock: ok dcf is 6 fixline(6, 38400) {note the speed} ACU write ok(null) fixline(6, 38400) set interface 212 processdev: calling setdevcfg(, ACUSLIP) {the Devices entry used} gdial(zy1496) called {the Dialers entry used} expect: ("") {this is in the Dialers script} got it sendthem (DELAY ^MPAUSE <NO CR>ATs2=128s0=0^M) expect: (OK^M) {it can talk to the modem!} ^MATs2=128s0=0^M^M^JOK^Mgot it sendthem (<NO CR>ATdtw3906041^M) {dialing the phone number} expect: (CONNECT) {answered!} ^JATdtw3906041^M^M^JCONNECTgot it {connected} getto ret 6 expect: ("") {starting the chat script in Systems} got it sendthem (<NO CR>^M) expect: (ogin:) 38400/V32b 14400/V42b^M^J^M^J^M^JTelebit's NetBlazer Version 2.1^M^J^M^Jslipserv login:got it sendthem (Poniboshi^M) {sending the login ID} expect: (assword:) Poniboshi^M^JPassword:got it sendthem (??????????^M) {I've protected my password} expect: (enabled) ^M^J^M^JPacket mode enabledgot it {now PPP negotiation starts} banner: ^M^J~^┐}#@!}!} } }8}!}$}%\}"}&} } } } }%}&}3^EJ}6}'}"}(}"F^E~ ppp slipserv: saving 53 bytes to salvage ppp slipserv: starting with /dev/ttyf1 debug=2 active_timeout=0 inactive=0 ppp slipserv: IPCP Initial (0)->Starting (1) ppp slipserv: LCP Initial (0)->Closed (2) ppp slipserv: LCP Closed (2)->Req-Sent (6) ppp slipserv: LCP Req-Sent (6)->Ack-Sent (8) ppp slipserv: LCP Ack-Sent (8)->Opened (9) ppp slipserv: MTU=1500 MRU=1500 accm=0 pcomp=y acomp=y my-magic=0x7fb6508b his=0x13854a16 ppp slipserv: entering Authenticate phase ppp slipserv: entering Network phase ppp slipserv: IPCP Starting (1)->Req-Sent (6) ppp slipserv: IPCP Req-Sent (6)->Ack-Sent (8) ppp slipserv: IPCP Ack-Sent (8)->Opened (9) ppp slipserv: 192.48.197.10 to 192.26.51.135 ppp slipserv: rx_vj_comp=y,tx=y rx_compslot=n,tx=n rx_slots=16,tx=15 {now PPP is up and running} If you get a timeout at any point instead of going on to the next part, this should be a strong indication of which part of the configuration to go back and re-check. APPENDIX SAMPLE GATED.CONF FILES Sample client /usr/etc/gated.conf: # gated.conf # ## Disclaimer: I am not a gated expert!!!!! ## in fact I know just enough to be dangerous ## use at your own risk! # # The information in the file is identified by the keywords which commence # at the start of a new line. Any text to the right of a # is a comment. # To change initialization info after egpup is running, kill the process # (which will initiate the correct cease message exchange) and restart it. RIP supplier HELLO no EGP no # Trace options # traceflags internal external route # use the server IP address instead of the IP address below net default gateway 192.102.100.1 metric 1 rip # # end Sample server /usr/etc/gated.conf: # gated.conf # ## Disclaimer: I am not a gated expert!!!!! ## in fact I know just enough to be dangerous ## use at your own risk! # # The information in the file is identified by the keywords which commence # at the start of a new line. Any text to the right of a # is a comment. # To change initialization info after egpup is running, kill the process # (which will initiate the correct cease message exchange) and restart it. RIP supplier HELLO no EGP no # Trace options # traceflags internal external route # use the network number and PPP-client IP address instead of the # numbers below net 192.102.101 gateway 192.102.101.1 metric 1 rip # # end